Method and system for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device and causing a notification to be generated

ABSTRACT

A method and system are provided for verifying whether a non-medical client device is operating correctly with a medical device controlled by the non-medical client device (NMCD) and causing a notification to be generated. In accordance with the method, an application at the non-medical client device monitors for occurrence of a trigger event and when a trigger event is detected, the application can perform one or more diagnostic checks to verify whether a medical control application at the NMCD is operating correctly. When the application determines that the one or more diagnostic checks have failed, the medical control application can attempt to initiate one or more remedial correction measures to restore the medical control application so that it is operating correctly. When the one or more remedial correction measures were unsuccessful, the application causes the notification to be generated via a user interface of the non-medical client device.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally tomedical devices and medical device systems and, more specifically, to amethod and medical device system, such as an insulin infusion system,for verifying whether a non-medical client device is operating correctlywith a medical device controlled by the non-medical client device. Anotification can be generated when one or more remedial correctionmeasures are unsuccessful to restore the non-medical client device sothat it is operating correctly.

BACKGROUND

Wireless devices, such as cellular telephones, mobile computers,personal digital assistants, digital media players, portable video gamedevices, and the like, and related wireless communication techniques andprotocols have become ubiquitous in modern society. More recently,portable medical devices having wireless data communication capabilitiesare becoming increasingly popular, especially for patients that haveconditions that must be monitored on a continuous or frequent basis. Forexample, diabetics are usually required to modify and monitor theirdaily lifestyle to keep their body in balance, in particular, theirblood glucose (“BG”) levels. Individuals with Type 1 diabetes and someindividuals with Type 2 diabetes use insulin to control their BG levels.To do so, diabetics routinely keep strict schedules, including ingestingtimely nutritious meals, partaking in exercise, monitoring BG levelsdaily, and adjusting and administering insulin dosages accordingly.Diabetics may utilize wireless medical devices that are deployed in anetwork environment in a manner that facilitates data communicationbetween two or more separate devices.

In the past, on-body medical devices, such as fluid infusion device (orinfusion pump) and sensing arrangement (e.g., continuous glucosesensors), could be controlled using a custom controller device (CCD).Today, there is a growing trend towards controlling personal medicaldevices, such as insulin infusion devices that are worn by a patient,using a non-medical device such as a patient's smart phone, laptop ortablet. On-body medical devices can now be communicated with andcontrolled using a non-medical smart device (e.g., smartphone, tablet).One advantage of this approach is that is can eliminate the need for apatient to possess and use another distinct control device. This canmake the cost of ownership lower. In addition, patients can be discreetin managing their disease, and use a familiar user interface andform-factor which shortens the learning curve. This can also provideconnectivity to back end systems (e.g., cloud-based systems) that areused to monitor patients and control delivery of medication to apatient. Non-medical smart devices can upload data for analysis byhealth care providers (HCPs) and AI-based systems. Non-medical smartdevices can also receive regular updates to therapy management software.For instance, these updates can update medical control applicationsoftware (or key parameters thereof) to customize and improve therapy.Connectivity also provides the means to alert caregivers and HCPs inemergency situations when concerning trends are present. A medicalcontrol application can also use health related data from thenon-medical smart device and other apps/systems to improve therapy forthe patient.

A number of insulin pump systems are designed to deliver accurate andmeasured doses of insulin via infusion sets (an infusion set deliversthe insulin through a small diameter tube that terminates at a cannulainserted under the patient's skin). In lieu of a syringe, the patientcan simply activate the insulin pump to administer an insulin bolus asneeded, for example, in response to the patient's current BG level. Apatient can measure his BG level using a BG measurement device, such asa test strip meter, a continuous glucose measurement system, or thelike. BG measurement devices use various methods to measure the BG levelof a patient, such as a sample of the patient's blood, a sensor incontact with a bodily fluid, an optical sensor, an enzymatic sensor, ora fluorescent sensor. When the BG measurement device has generated a BGmeasurement, the measurement is displayed on the BG measurement device.A continuous glucose monitoring system can monitor the patient's sensorglucose (SG) level (e.g., subcutaneous tissue glucose level) inreal-time. This allows delivery of insulin to be calculated in real-timewith dosage calculated in a software algorithm based on measured sensorglucose level, or a closed-loop algorithm.

The insulin pump, continuous glucose monitoring (CGM) device, and otherdevices, such as a smartphone and a Blood Glucose Monitor (BGM), can bedifferent parts of an insulin infusion system. The various devices thatare part of the insulin infusion system can form a wireless body areanetwork that can be used, for example, to exchange monitor and therapy(control) data among multiple medical devices that are either worn on ornear a patient's body. For instance, therapy data such as measuredglucose values (SG values) and therapy settings (parameters for bolusdelivery) can be transferred wirelessly among devices within the bodyarea network. Insulin pumps and CGM devices may also be configured tocommunicate with remote control devices, monitoring or display devices,BG meters, and other devices associated with such an infusion system.For example, a CGM sensor may include or cooperate with a wireless radiofrequency (“RF”) transmitter that communicates with other devices thatare part of an infusion system such as a handheld remote control (alsocalled a command control device (CCD)) that communicates with theinfusion pump device using wireless communication technologies such asclassical Bluetooth® (BT) or Bluetooth Low Energy® (BLE) technologies.

The insulin infusion device and the smartphone can both include displaysand different types of alarms to alert a user when they are notoperating correctly. For instance, with respect to the insulin infusiondevice, if a microcontroller of the insulin infusion device fails, anotification (e.g., a message on a display, an audible or visual alarmor other type of alert such as a vibration) can be activated to informthe user that their insulin infusion device is not operating correctly.

While using non-medical devices such smartphones can provide a number ofadvantages, one risk from the perspective of medical devicemanufacturers is that a smartphone or other smart devices are arelatively open platform and not as controllable as a medical device.

Accordingly, it is desirable to provide a medical device system, such asan insulin infusion system, that can verify whether a non-medical clientdevice (e.g., smartphone or other smart device) is operating correctlywith a wearable medical device (e.g., insulin infusion device) that iscontrolled by the non-medical client device. It would also be desirableto reduce risk associated with using a smartphone. Furthermore, otherdesirable features and characteristics will become apparent from thesubsequent detailed description and the appended claims, taken inconjunction with the accompanying drawings and the foregoing technicalfield and background.

BRIEF SUMMARY

In one embodiment, a method is provided for verifying whether anon-medical client device is operating correctly with a medical devicecontrolled by the non-medical client device and causing a notificationto be generated. In accordance with the method, an application at thenon-medical client device monitors for occurrence of a trigger event andwhen the non-medical client device detects occurrence of the triggerevent, the application at the non-medical client device can perform oneor more diagnostic checks to verify whether a medical controlapplication at the non-medical client device is operating correctly.When the application at the non-medical client device determines thatthe one or more diagnostic checks have failed, the medical controlapplication at the non-medical client device can attempt to initiate oneor more remedial correction measures to restore the medical controlapplication so that it is operating correctly, and when the one or moreremedial correction measures were unsuccessful, the application at thenon-medical client device causes the notification to be generated via auser interface of the non-medical client device.

In one embodiment, the notification can be a first notification, andafter causing the first notification to be generated via the userinterface of the non-medical client device, a counter can be started atthe non-medical client device. The application at the non-medical clientdevice can then regularly determine whether an acknowledgement signalwas generated to acknowledge the first notification. When a count of thecounter exceeds a threshold count and no acknowledgement signal wasgenerated to acknowledge the first notification, a second notificationis caused to be generated via a second user interface of the medicaldevice. The second notification is used to alert a user that the firstnotification generated at the non-medical client device has not beenacknowledged so that other remedial measures can be taken at thenon-medical client device.

In one embodiment, the application at the non-medical client device canperform a communication link verification process, when the applicationat the non-medical client device detects occurrence of the triggerevent, to determine whether the non-medical client device has anestablished communication link to the medical device. When theapplication at the non-medical client device determines that thenon-medical client device does not haves a communication link to themedical device, it can attempt attempting to establish a communicationlink between the non-medical client device and the medical device. Inone embodiment, a first notification is caused to be generated via theuser interface of the non-medical client device when the attempt toestablish the communication link between the non-medical client deviceand the medical device is unsuccessful, and when the attempt toestablish the communication link between the non-medical client deviceand the medical device is unsuccessful, a second notification is causedto be generated via a second user interface of the medical device.

In one embodiment, the application at the non-medical client device caninitiate a verification protocol when the application at the non-medicalclient device detects occurrence of the trigger event. The verificationprotocol can include executing one or more diagnostic checks to verifywhether the medical control application is functioning properly and hasaccess to adequate computing resources. The computing resources mayinclude processing resources, communication resources, user interfaceresources, and memory resources.

In one embodiment, the trigger event comprises one or more of: receivingan indication that a notification needs to be acknowledged; receiving anindication that a notification needs to be activated; receiving anindication that a notification has been issued; receiving an indicationthat a timer has expired; and receiving an indication that a counter hasa count that exceeds a threshold count.

In one embodiment, the one or more diagnostic checks to verify whetherthe medical control application is operating correctly comprise one ormore of: determining whether an operating system version is up to date;determining whether the medical control application is up to date;determining whether settings of the medical control application arecorrect; determining whether the medical control application is loadingproperly; and determining whether the medical control application isrunning properly.

In one embodiment, the one or more remedial correction measures attemptto correct issues that are causing the non-medical client device to runimproperly so that the medical control application will functioncorrectly and have access to required computing resources.

In one embodiment, the one or more remedial correction measures compriseone or more of: automatically closing and restarting the medical controlapplication; prompting the user to change restart the medical controlapplication of the non-medical client device when it is determined thatthe medical control application is not loading or is not runningproperly; automatically powering the non-medical client device off,automatically restarting non-medical client device and reopening themedical control application; downloading and installing an up-to-dateversion of the medical control application or an up-to-date version ofan operating system when it is determined that the existing versionswere not correct; prompting the user to change one or more settings ofthe medical control application when it is determined that one or moresettings of the medical control application are incorrect; and freeingup additional computing resources of the non-medical client device foruse by the medical control application when it is determined that themedical control application does not have access to adequate computingresources.

In one embodiment, the non-medical client device comprises: asmartphone, and the medical device comprises one of an insulin infusiondevice that is configured to be controlled via the medical controlapplication executed at the smartphone, and a glucose sensorarrangement.

In another embodiment, a non-medical client device is provided that isconfigured to execute a medical control application that controls amedical device. The non-medical client device comprises: at least oneprocessor device; and a non-transitory processor-readable mediumoperatively associated with the at least one processor device. Theprocessor-readable medium comprises executable instructions configurableto cause the at least one processor device to perform a method forverifying whether the non-medical client device is operating correctlywith the medical device and causing a notification to be generated. Themethod comprises: monitoring for occurrence of a trigger event via anapplication at the non-medical client device; performing, via theapplication at the non-medical client device when the application at thenon-medical client device detects occurrence of the trigger event, oneor more diagnostic checks to verify whether a medical controlapplication at the non-medical client device is operating correctly;attempting to initiate one or more remedial correction measures via theapplication to restore the medical control application at thenon-medical client device so that it is operating correctly when theapplication at the non-medical client device determines that the one ormore diagnostic checks have failed; and causing, via the application,the notification to be generated via a user interface of the non-medicalclient device when the one or more remedial correction measures wereunsuccessful.

In another embodiment, a wireless body area network for an insulininfusion system is provided. The wireless body area network includes aplurality of devices that are part of the wireless body area network,the plurality of devices comprising: a non-medical client device and amedical device configured to be controlled by a medical controlapplication executed by the non-medical client device. The non-medicalclient device comprises: a processor device; and a non-transitoryprocessor-readable medium operatively associated with the processordevice. The processor-readable medium comprises executable instructionsconfigurable to cause the processor device to perform a method forverifying whether the non-medical client device is operating correctlywith the medical device and causing a notification to be generated. Themethod comprises: monitoring for occurrence of a trigger event via anapplication at the non-medical client device; performing, via theapplication at the non-medical client device when the application at thenon-medical client device detects occurrence of the trigger event, oneor more diagnostic checks to verify whether a medical controlapplication at the non-medical client device is operating correctly;attempting to initiate one or more remedial correction measures via theapplication to restore the medical control application at thenon-medical client device so that it is operating correctly when theapplication at the non-medical client device determines that the one ormore diagnostic checks have failed; and causing, via the application,the notification to be generated via a user interface of the non-medicalclient device when the one or more remedial correction measures wereunsuccessful.

In one embodiment, the notification is a first notification, and themethod further comprises: starting a counter at the non-medical clientdevice after causing the first notification to be generated via the userinterface of the non-medical client device; regularly determining, viathe application at the non-medical client device, whether anacknowledgement signal was generated to acknowledge the firstnotification; and causing a second notification to be generated via asecond user interface of the medical device when a count of the counterexceeds a threshold count and no acknowledgement signal was generated toacknowledge the first notification. The second notification is used toalert a user that the first notification generated at the non-medicalclient device has not been acknowledged so that other remedial measurescan be taken at the non-medical client device.

In one embodiment, the trigger event comprises one or more of: receivingan indication that a notification needs to be acknowledged; receiving anindication that a notification needs to be activated; receiving anindication that a notification has been issued; receiving an indicationthat a timer has expired; and receiving an indication that a counter hasa count that exceeds a threshold count. The one or more diagnosticchecks to verify whether the medical control application is operatingcorrectly comprise one or more of: determining whether an operatingsystem version is up to date; determining whether the medical controlapplication is up to date; determining whether settings of the medicalcontrol application are correct; determining whether the medical controlapplication is loading properly; and determining whether the medicalcontrol application is running properly.

In one embodiment, the application at the non-medical client deviceinitiates a verification protocol when the application at thenon-medical client device detects occurrence of the trigger event. Theverification protocol comprises: executing one or more diagnostic checksto verify whether the medical control application is functioningproperly and has access to adequate computing resources, wherein thecomputing resources include processing resources, communicationresources, user interface resources, and memory resources.

In one embodiment, the one or more remedial correction measures attemptto correct issues that are causing the non-medical client device to runimproperly so that the medical control application will functioncorrectly and have access to required computing resources. The one ormore remedial correction measures comprise one or more of: automaticallyclosing and restarting the medical control application; prompting theuser to change restart the medical control application of thenon-medical client device when it is determined that the medical controlapplication is not loading or is not running properly; automaticallypowering the non-medical client device off, automatically restartingnon-medical client device, and reopening the medical controlapplication; downloading and installing an up-to-date version of themedical control application or an up-to-date version of an operatingsystem when it is determined that the existing versions were notcorrect; prompting the user to change one or more settings of at leastone of the medical control application, the non-medical client device oran operating system of the non-medical client device when it isdetermined that one or more settings of the medical control applicationare incorrect; and freeing up additional computing resources of thenon-medical client device for use by the medical control applicationwhen it is determined that the medical control application does not haveaccess to adequate computing resources.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures.

FIG. 1 depicts an exemplary embodiment of an infusion system;

FIG. 2 is a simplified block diagram representation of an exemplaryembodiment of a communication system;

FIG. 3 is a simplified block diagram representation of an exemplaryembodiment of a computer-based or processor-based device in accordancewith the disclosed embodiments.

FIG. 4 is a method for verifying whether a communication link between anon-medical client device and a medical device is established and forcausing a notification to be issued at a non-medical client deviceand/or a medical device when the communication link is not establishedin accordance with the disclosed embodiments;

FIG. 5 is a method for verifying that a non-medical client device and amedical control application are operating/functioning properly inaccordance with the disclosed embodiments; and

FIG. 6 is a method for generating a notification at a medical devicewhen a notification generated at a non-medical client device is notacknowledged in accordance with the disclosed embodiments.

DETAILED DESCRIPTION

The following detailed description is merely illustrative in nature andis not intended to limit the embodiments of the subject matter or theapplication and uses of such embodiments. As used herein, the word“exemplary” means “serving as an example, instance, or illustration.”Any implementation described herein as exemplary is not necessarily tobe construed as preferred or advantageous over other implementations.Furthermore, there is no intention to be bound by any expressed orimplied theory presented in the preceding technical field, background,brief summary or the following detailed description.

Techniques and technologies may be described herein in terms offunctional and/or logical block components, and with reference tosymbolic representations of operations, processing tasks, and functionsthat may be performed by various computing components or devices. Suchoperations, tasks, and functions are sometimes referred to as beingcomputer-executed, computerized, software-implemented, orcomputer-implemented. It should be appreciated that the various blockcomponents shown in the figures may be realized by any number ofhardware, software, and/or firmware components configured to perform thespecified functions. For example, an embodiment of a system or acomponent may employ various integrated circuit components, e.g., memoryelements, digital signal processing elements, logic elements, look-uptables, or the like, which may carry out a variety of functions underthe control of one or more microprocessors or other control devices.

When implemented in software, firmware, or processor-readableinstructions, various elements of the systems described herein areessentially the code segments or instructions that perform the varioustasks. In certain embodiments, the program or code segments are storedin a tangible processor-readable medium, which may include any mediumthat can store or transfer information. Examples of a non-transitory andprocessor-readable medium include an electronic circuit, a semiconductormemory device, a ROM, a flash memory, an erasable ROM (EROM), a floppydiskette, a CD-ROM, an optical disk, a hard disk, or the like.

Exemplary embodiments of the subject matter described herein areimplemented in conjunction with medical devices, such as portableelectronic medical devices. Although many different applications arepossible, the following description focuses on embodiments thatincorporate an insulin infusion device (or insulin pump) as part of aninfusion system deployment. For the sake of brevity, conventionaltechniques related to infusion system operation, insulin pump and/orinfusion set operation, and other functional aspects of the systems (andthe individual operating components of the systems) may not be describedin detail here. Examples of infusion pumps may be of the type describedin, but not limited to, U.S. Pat. Nos. 4,562,751; 4,685,903; 5,080,653;5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351;6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893;each of which are herein incorporated by reference.

Generally, a fluid infusion device includes a motor or other actuationarrangement that is operable to linearly displace a plunger (or stopper)of a fluid reservoir provided within the fluid infusion device todeliver a dosage of fluid, such as insulin, to the body of a user.Dosage commands that govern operation of the motor may be generated inan automated manner in accordance with the delivery control schemeassociated with a particular operating mode, and the dosage commands maybe generated in a manner that is influenced by a current (or mostrecent) measurement of a physiological condition in the body of theuser. For example, in a closed-loop or automatic operating mode, dosagecommands may be generated based on a difference between a current (ormost recent) measurement of the interstitial fluid glucose level in thebody of the user and a target (or reference) glucose setpoint value. Inthis regard, the rate of infusion may vary as the difference between acurrent measurement value and the target measurement value fluctuates.For purposes of explanation, the subject matter is described herein inthe context of the infused fluid being insulin for regulating a glucoselevel of a user (or patient); however, it should be appreciated thatmany other fluids may be administered through infusion, and the subjectmatter described herein is not necessarily limited to use with insulin.

Smart devices (e.g., smartphones) are devices that are available to thegeneral public and have other uses beyond medical applications. Usingsuch non-medical devices as part of a medical device system can providea number of advantages. However, from the perspective of medical devicemanufacturers, one concern with using such non-medical devices tocontrol medical devices is their open nature, reliability and securitybecause smart devices are relatively open platforms and not ascontrollable as a medical device. Other than writing the code for amedical control application that is implemented on a patient's smartdevice, medical device manufacturers have little control of thepatient's smart device to ensure that it is working correctly. Forexample, the medical device manufacturer does not write the operatingsystem used by the smart device, has no control over installation of themost up-to-date software on the smart device (including the medicalcontrol application), cannot control what the user does to settings onthe smart device, etc. For example, there is no way to ensure that apatient updates operating system (OS) software and other apps, or that apatient properly configures settings of the non-medical smart device. Inaddition, the availability of required computing resources on thenon-medical smart device can affect functionality of the system. Bycontrast, because medical devices are is designed by devicemanufacturers there is more control over their operations and settingsthey are thus considered more reliable.

In addition, users can control operation of their smart device andchange settings (e.g., volume settings, wireless communication interfacesettings), etc. For example, users are responsible for controllingsettings of their smart device, what other devices they are connectedto, usage of computing resources, updates to the operating system orother application software (including what applications are installedand potentially conflict with a medical control application), etc. Aneed may arise to notify or alert the user (e.g., when the patient'sblood glucose level goes low), but certain settings on the smart devicemay be set in a way that prevents this from happening. As an example,Bluetooth maybe in use for a phone call, speakers may be in use forlistening to music, or the device's volume might be turned off. Inshort, this open nature of smart devices creates a potential risk that amedical control application executed at the smart device may not operateas intended.

To address these issues a medical device system, such as an insulininfusion system, is provided that can verify whether a non-medicalclient device (e.g., smartphone or other smart device) is operatingcorrectly with a wearable medical device (e.g., insulin infusion device)that is controlled by the non-medical client device. This system canreduce risk associated with using a smart device such as a smartphone,and increase the likelihood that a patient can continue to getnotifications in the event that their smartphone, or the medical controlapplication executed on their smartphone, fails. For instance, thesystem can allow patients to continue to receive alerts, alarms, andother warnings concerning their medical devices when needed even thoughtheir smart device (or non-medical device) may not be communicatingthem, or even though a medical control application that runs on theirsmart device is not operating as intended. For example, the system canallow patients to continue to receive alerts, alarms, and other warningswhen a battery dies on the patient's smartphone, or when the userswitches a communication interface (like a Bluetooth interface) so thatit is linked to another device, or when the user turns the volume onsmartphone off so that alarms generated by the application are notaudible to the patient, or when the medical control application fails tooperate as intended for any reason.

In one embodiment, methods, systems and apparatus are provided forverifying whether a non-medical client device is operating correctlywith a medical device controlled by the non-medical client device andcausing a notification to be generated. The medical device and thenon-medical client device can be part of a wireless body area networkfor a medical device system, namely, an insulin infusion system. Inaccordance with certain embodiments, the insulin infusion systemincludes an insulin infusion device configured to deliver insulin to auser, a glucose sensor arrangement, a mobile, non-medical client devicesuch as a smartphone, etc. For example, the non-medical client devicecan be smartphone, and the medical device can be an insulin infusiondevice that is configured to be controlled via the medical controlapplication executed at the smartphone.

In one embodiment, an application at the non-medical client device canmonitor for occurrence of a trigger event, and when the application atthe non-medical client device detects occurrence of the trigger event,the application at the non-medical client device can perform one or morediagnostic checks to verify whether a medical control application at thenon-medical client device is operating correctly. For example, in oneimplementation, the trigger event can be one or more of: receiving anindication that a notification needs to be acknowledged; receiving anindication that a notification needs to be activated; receiving anindication that a notification has been issued; receiving an indicationthat a timer has expired; and receiving an indication that a counter hasa count that exceeds a threshold count. Further, in one implementation,the one or more diagnostic checks can include one or more of:determining whether an operating system version is up to date;determining whether the medical control application is up to date;determining whether settings of the medical control application arecorrect; determining whether the medical control application is loadingproperly; and determining whether the medical control application isrunning properly.

When the application at the non-medical client device determines thatthe one or more diagnostic checks have failed (e.g., this can mean thatthe medical control application is not operating correctly), theapplication can attempt to initiate one or more remedial correctionmeasures to restore the medical control application so that it isoperating correctly. The one or more remedial correction measuresattempt to correct issues that are causing the non-medical client deviceto run improperly so that the medical control application will functioncorrectly and have access to required computing resources (e.g., memory,processing, user interfaces, communication interfaces, powersources/supplies, etc.). For example, in one implementation, theremedial correction measures can include one or more of: automaticallyclosing and restarting the medical control application; prompting theuser to change restart the medical control application of thenon-medical client device when it is determined that the medical controlapplication is not loading or is not running properly; automaticallypowering the non-medical client device off, automatically restartingnon-medical client device and reopening the medical control application;downloading and installing an up-to-date version of the medical controlapplication or an up-to-date version of an operating system when it isdetermined that the existing versions were not correct; prompting theuser to change one or more settings of the medical control applicationwhen it is determined that one or more settings of the medical controlapplication are incorrect; and freeing up additional computing resourcesof the non-medical client device for use by the medical controlapplication when it is determined that the medical control applicationdoes not have access to adequate computing resources.

When the one or more remedial correction measures are unsuccessful, theapplication causes a first notification to be generated via a userinterface of the non-medical client device, and can start a counterafter causing the notification to be generated. Thereafter, theapplication at the non-medical client device can regularly determinewhether an acknowledgement signal was generated to acknowledge thenotification. When a count of the counter exceeds a threshold count andno acknowledgement signal was generated to acknowledge the firstnotification, the application can cause a second notification to begenerated via a second user interface of the medical device. The secondnotification is used to alert a user that thee first notificationgenerated at the non-medical client device has not been acknowledged sothat other remedial measures can be taken at the non-medical clientdevice.

For instance, in one implementation, the application at the non-medicalclient device can initiate a verification protocol when it detects theoccurrence of the trigger event. The verification protocol can includeexecuting diagnostic checks to verify whether the medical controlapplication is functioning properly and has access to adequate computingresources (e.g., processing resources, communication resources, userinterface resources, memory resources).

In another embodiment, the application at the non-medical client devicecan perform a communication link verification process, when theapplication detects occurrence of the trigger event, to determinewhether the non-medical client device has an established communicationlink to the wearable medical device. When the application at thenon-medical client device determines that the non-medical client devicedoes not haves a communication link to the wearable medical device, theapplication can attempt to establish a communication link between thenon-medical client device and the medical device, and if the attempt toestablish the communication link is unsuccessful, the application cancause a first notification to be generated via the user interface of thenon-medical client device, and/or cause a second notification to begenerated via a second user interface of the medical device.

In yet another embodiment, a method is provided for an application onthe non-medical device (e.g., smartphone, tablet or laptop) to takecontrol of the insulin pump to issue a notification or an alert (e.g.,activate an audio or visual alarm, activate a haptic signal). Thisprovides a way to let a patient know that their non-medical device maynot be operating as intended to alert them that some action needs to betaken. In one implementation, a smartphone can periodically check tomake sure that an application and/or the smartphone that runs theapplication are working as required. For example, whenever informationindicates that an alarm needs to be issued, a check can be performed tomake sure that the application and/or smartphone that runs theapplication are operating correctly. This way, the system can determinewhether everything is connected and working properly so that the userknows if the medical control application is working correctly or asintended. If everything is not connected or working properly, thenbackup alert system or alarm on the body-worn medical device (e.g., CGM,insulin pump, or both) can be used as a backup to notify the user thatthe non-medical device or application it is executing is not operatingproperly or optimally as recommended (e.g., alert the user that theapplication and/or smartphone that runs the application are not workingas required, and/or to alert the user that some action needs to betaken).

Turning now to FIG. 1, one exemplary embodiment of an infusion system100 includes, without limitation, a fluid infusion device (or infusionpump) 102, a sensing arrangement 104, a command control device (CCD)106, and a computer 108. The components of an infusion system 100 may berealized using different platforms, designs, and configurations, and theembodiment shown in FIG. 1 is not exhaustive or limiting. In practice,the infusion device 102 and the sensing arrangement 104 are secured atdesired locations on the body of a user (or patient), as illustrated inFIG. 1. In this regard, the locations at which the infusion device 102and the sensing arrangement 104 are secured to the body of the user inFIG. 1 are provided only as a representative, non-limiting, example. Theelements of the infusion system 100 may be similar to those described inU.S. Pat. No. 8,674,288, the subject matter of which is herebyincorporated by reference in its entirety.

In the illustrated embodiment of FIG. 1, the infusion device 102 isdesigned as a portable medical device suitable for infusing a fluid, aliquid, a gel, or other medicament into the body of a user. In exemplaryembodiments, the infused fluid is insulin, although many other fluidsmay be administered through infusion such as, but not limited to, HIVdrugs, drugs to treat pulmonary hypertension, iron chelation drugs, painmedications, anti-cancer treatments, medications, vitamins, hormones, orthe like. In some embodiments, the fluid may include a nutritionalsupplement, a dye, a tracing medium, a saline medium, a hydrationmedium, or the like.

The sensing arrangement 104 generally represents the components of theinfusion system 100 configured to sense, detect, measure or otherwisequantify a condition of the user, and may include a sensor, a monitor,or the like, for providing data indicative of the condition that issensed, detected, measured or otherwise monitored by the sensingarrangement. In this regard, the sensing arrangement 104 may includeelectronics and enzymes reactive to a biological condition, such as ablood glucose level, or the like, of the user, and provide dataindicative of the blood glucose level to the infusion device 102, theCCD 106 and/or the computer 108. For example, the infusion device 102,the CCD 106 and/or the computer 108 may include a display for presentinginformation or data to the user based on the sensor data received fromthe sensing arrangement 104, such as, for example, a current glucoselevel of the user, a graph or chart of the user's glucose level versustime, device status indicators, alert messages, or the like. In otherembodiments, the infusion device 102, the CCD 106 and/or the computer108 may include electronics and software that are configured to analyzesensor data and operate the infusion device 102 to deliver fluid to thebody of the user based on the sensor data and/or preprogrammed deliveryroutines. Thus, in exemplary embodiments, one or more of the infusiondevice 102, the sensing arrangement 104, the CCD 106, and/or thecomputer 108 includes a transmitter, a receiver, and/or othertransceiver electronics that allow for communication with othercomponents of the infusion system 100, so that the sensing arrangement104 may transmit sensor data or monitor data to one or more of theinfusion device 102, the CCD 106 and/or the computer 108.

Still referring to FIG. 1, in various embodiments, the sensingarrangement 104 may be secured to the body of the user or embedded inthe body of the user at a location that is remote from the location atwhich the infusion device 102 is secured to the body of the user. Invarious other embodiments, the sensing arrangement 104 may beincorporated within the infusion device 102. In other embodiments, thesensing arrangement 104 may be separate and apart from the infusiondevice 102, and may be, for example, part of the CCD 106. In suchembodiments, the sensing arrangement 104 may be configured to receive abiological sample, analyte, or the like, to measure a condition of theuser.

In some embodiments, the CCD 106 and/or the computer 108 may includeelectronics and other components configured to perform processing,delivery routine storage, and to control the infusion device 102 in amanner that is influenced by sensor data measured by and/or receivedfrom the sensing arrangement 104. By including control functions in theCCD 106 and/or the computer 108, the infusion device 102 may be madewith more simplified electronics. However, in other embodiments, theinfusion device 102 may include all control functions, and may operatewithout the CCD 106 and/or the computer 108. In various embodiments, theCCD 106 may be a portable electronic device. In addition, in variousembodiments, the infusion device 102 and/or the sensing arrangement 104may be configured to transmit data to the CCD 106 and/or the computer108 for display or processing of the data by the CCD 106 and/or thecomputer 108.

In some embodiments, the CCD 106 and/or the computer 108 may provideinformation to the user that facilitates the user's subsequent use ofthe infusion device 102. For example, the CCD 106 may provideinformation to the user to allow the user to determine the rate or doseof medication to be administered into the user's body. In otherembodiments, the CCD 106 may provide information to the infusion device102 to autonomously control the rate or dose of medication administeredinto the body of the user. In some embodiments, the sensing arrangement104 may be integrated into the CCD 106. Such embodiments may allow theuser to monitor a condition by providing, for example, a sample of hisor her blood to the sensing arrangement 104 to assess his or hercondition. In some embodiments, the sensing arrangement 104 and the CCD106 may be used for determining glucose levels in the blood and/or bodyfluids of the user without the use of, or necessity of, a wire or cableconnection between the infusion device 102 and the sensing arrangement104 and/or the CCD 106.

In some embodiments, the sensing arrangement 104 and/or the infusiondevice 102 are cooperatively configured to utilize a closed-loop systemfor delivering fluid to the user. Examples of sensing devices and/orinfusion pumps utilizing closed-loop systems may be found at, but arenot limited to, the following U.S. Pat. Nos. 6,088,608, 6,119,028,6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153 or UnitedStates Patent Application Publication No. 2014/0066889, all of which areincorporated herein by reference in their entirety. In such embodiments,the sensing arrangement 104 is configured to sense or measure acondition of the user, such as, blood glucose level or the like. Theinfusion device 102 is configured to deliver fluid in response to thecondition sensed by the sensing arrangement 104. In turn, the sensingarrangement 104 continues to sense or otherwise quantify a currentcondition of the user, thereby allowing the infusion device 102 todeliver fluid continuously in response to the condition currently (ormost recently) sensed by the sensing arrangement 104 indefinitely. Insome embodiments, the sensing arrangement 104 and/or the infusion device102 may be configured to utilize the closed-loop system only for aportion of the day, for example only when the user is asleep or awake.

FIG. 2 is a simplified block diagram representation of an exemplaryembodiment of a communication system 200 that is suitably configured tosupport the techniques and methodologies described in more detail below.The system 200 supports users of insulin infusion devices, and performsvarious techniques and methods to help users (patients, caregivers,healthcare providers, parents, etc.) manage the use of insulin infusiondevices. It should be appreciated that FIG. 2 depicts one possibleimplementation of a communication system, and that other arrangements,architectures, and deployments can be provided if so desired. The system200 (which has been simplified for purposes of illustration) generallyincludes or cooperates with the following components, withoutlimitation: a mobile device 204; an insulin infusion device 206; a bloodglucose meter 208; a continuous glucose sensor 210; and an optional datauploader 212. The mobile device 204 is a client device that is owned oroperated by the user, i.e., a diabetic patient. The insulin infusiondevice 206, the blood glucose meter 208, and the glucose sensor 210 arecomponents of an insulin infusion system that is used by the patient totreat diabetes. The system 200 may also include or cooperate with theoptional data uploader component 212.

The various components of the system 200 can be used to collect andanalyze input data for the patient that can originate from varioussources, including an insulin infusion device, a glucose sensor ormeter, a mobile device operated by a user of the insulin infusiondevice, or other components or computing devices that are compatiblewith the system, such as a data uploader. These and other alternativearrangements are contemplated by this disclosure. To this end, someembodiments of the system may include additional devices and componentsthat serve as data sources, data processing units, etc. For example, thesystem may include any or all of the following elements, withoutlimitation: computer devices or systems; patient monitors; healthcareprovider systems; data communication devices; and the like. It should beappreciated that the insulin infusion device 206 can be an optionalcomponent in some applications (for example, for Type 2 diabetespatients). For such applications, another diabetes management deviceand/or the mobile device 204 can function in an equivalent manner tosupport the system 200.

At a minimum, the mobile device 204 is communicatively coupled to anetwork 214. In certain embodiments, the insulin infusion device 206,the blood glucose meter 208, and/or the continuous glucose sensor 210are also communicatively coupled to the network 214 to facilitate theuploading of relevant data to a remote server system (not illustrated).Alternatively, or additionally, the insulin infusion device 206, theblood glucose meter 208, and the continuous glucose sensor 210 providerelevant data to the data uploader component 212, which in turn uploadsthe data to other systems (not illustrated) via the network 214.

FIG. 2 depicts the network 214 in a simplified manner. In practice, thesystem 200 may cooperate with and leverage any number of wireless andany number of wired data communication networks maintained or operatedby various entities and providers. Accordingly, communication betweenthe various components of the system 200 may involve multiple networklinks and different data communication protocols. In this regard, thenetwork 214 can include or cooperate with any of the following, withoutlimitation: a local area network; a wide area network; the Internet; apersonal area network; a cellular communication network; a satellitecommunication network; a video services or television broadcastingnetwork; a network onboard a vehicle; or the like. In addition, thevarious components can also communicate directly with each other usingNFMI radio communications; NFeMI radio communications, BLE®communications, classical Bluetooth® (BT) communications, WLAN (or“Wi-Fi”) communications, or indirectly with each other using WLAN orcellular communications, as will be described below. The components ofthe system may be suitably configured to support a variety of wirelessand wired data communication protocols, technologies, and techniques asneeded for compatibility with the network 214.

The mobile device 204 can be realized using a variety of differentdevice platforms. For example, the mobile device 204 can be implementedas any of the following, without limitation: a cellular telephone orsmartphone; a portable computer (e.g., a laptop, a tablet, or a netbookcomputer); a portable media player; a portable video game device; aportable medical device; a navigation device such as a globalpositioning system (GPS) device; a wearable computing device; anelectronic toy or game; etc. In accordance with certain exemplaryembodiments, the mobile device 204 supported by the system 200 isimplemented as a computer-based or processor-based component. Forsimplicity and ease of illustration, FIG. 2 depicts only one mobiledevice 204. In practice, however, the system 200 is suitably configuredto support a plurality of mobile devices 204, where the patient or userowns or operates at least one of the supported mobile devices 204. Anexemplary embodiment of a device suitable for implementing the mobiledevice 204 is described below with reference to FIG. 3.

The remainder of this description assumes that the mobile device 204 isa smartphone used by the particular patient. To this end, theconfiguration and general functionality of the mobile device 204 can besubstantially consistent with conventional smartphone design. In thisregard, a suitably designed mobile app is installed on the mobile device204 to allow the patient to receive, view, and interact with messagesand notifications provided by the system. The mobile app installed onthe mobile device 204 can also be utilized to provide relevant data toother systems (not illustrated) for storage and analysis. For example,the mobile app can manage and upload the following information, withoutlimitation: calendar data (time of day, day of the week, month, season,etc.); user profile data; GPS data that indicates the geographicposition of the mobile device 204; map or navigation data associatedwith operation of the mobile device 204; user-entered meal consumption,food content, and/or food ingredient data; user-entered carbohydratedata; user-entered exercise related data; user-entered medicationrelated data; user response data associated with the receipt of glycemicinsight messages; user feedback related to glycemic insight messages;accelerometer data; contacts list information; web browser data;consumer purchasing data; and the like.

In certain embodiments, the insulin infusion device 206 is a portablepatient-worn or patient-carried component that is operated to deliverinsulin into the body of the patient via, for example, an infusion set.In accordance with certain exemplary embodiments, each insulin infusiondevice 206 supported by the system 200 is implemented as acomputer-based or processor-based component. For simplicity and ease ofillustration, FIG. 2 depicts only one insulin infusion device 206. Inpractice, however, the system 200 is suitably configured to support aplurality of insulin infusion device 206, wherein each patient or userowns or operates at least one of the insulin infusion devices 206. Anexemplary embodiment of a device suitable for implementing the insulininfusion device 206 is described below with reference to FIG. 3.

The system 200 obtains input data from one or more sources, which mayinclude various diabetes management devices (an insulin infusion device,a continuous glucose monitoring device, a glucose sensor, a monitordevice, or the like). In this regard, the insulin infusion device 206represents a source of input data for the system 200. In certainembodiments, the insulin infusion device 206 provides data that isassociated with its operation, status, insulin delivery events, and thelike. As mentioned previously, relevant data generated or collected bythe insulin infusion device 206 can be transmitted directly orindirectly to other components of the system including the data uploadercomponent 212, depending on the particular implementation of the system200. The particular type of data provided by the insulin infusion device206 is described in more detail below.

The patient or user can own or operate the blood glucose meter 208. Theblood glucose meter 208 is configured to measure the blood glucose levelof a user by analyzing a blood sample. For example, the blood glucosemeter 208 may include a receptacle for receiving a blood sample teststrip. In this regard, the user inserts a test strip into the bloodglucose meter 208, which analyzes the sample and displays a bloodglucose level corresponding to the test strip sample. The blood glucosemeter 208 may be configured to communicate the measured blood glucoselevel to the insulin infusion device 206 for storage and processing, tothe mobile device 204, or to the data uploader component 212. In somescenarios, the patient is responsible for entering each blood glucosemeasurement into the insulin infusion device 206. Ultimately, themeasured blood glucose data can be provided to any components of thesystem for analysis.

The glucose sensor 210 can be owned or operated by the patient or user.The glucose sensor 210 is suitably configured to measure a glucose level(interstitial) of the patient in real time. The glucose sensor 210 mayinclude a wireless transmitter that facilitates transmission of thesensor glucose data to other devices, such as the insulin infusiondevice 206 or the data uploader component 212 or other components of thesystem, where the sensor glucose data can be received for furtherprocessing.

Depending on the particular embodiment and application, the system 200can include or cooperate with other devices, systems, and sources ofinput data. Devices within the system 200 may be configured to supportthe transmission of data to various external devices, such as, withoutlimitation: a stationary monitor device, such as a bedside monitor or apiece of hospital monitoring equipment; a portable computer, such as alaptop PC, a palmtop PC, or a tablet PC; a stationary computer, such asa desktop PC; a personal digital assistant, which may also be a portableemail device; one or more additional computing devices or databases; orthe like. The above list of possible external devices is not exhaustive,and an implementation of the system 200 can be designed to accommodatecommunication with other systems, equipment, computing devices,components, and elements that are external to the system 200. Forexample, in certain embodiments the system 200 includes one or moresources of contextual information or data, which may include, withoutlimitation: activity tracker devices; meal logging devices or apps; moodtracking devices or apps; and the like.

The system 200 includes a local infusion system having one or more localdevices configured to wirelessly communicate with each other. Thisdescription may refer to the local infusion system as a “personal areanetwork” or a “body area network” of its constituent devices. Theselocal devices may be configured to transmit and receive localcommunications within the local infusion system, where such localcommunications are transmitted and received in accordance with one ormore specified local data communication protocols. For example, localcommunications may be exchanged between local devices using one or morewireless data communication protocols (which may leverage RF, infrared,magnetic induction, or other wireless techniques) and/or using one ormore wired data communication protocols. Thus, one or more of the localdevices can be considered to be a wireless medical device in the contextof this description. The local infusion system may be flexiblyconfigured such that any given local device can communicate with anyother local device, and a communication link or path between two localdevices may be unidirectional or bidirectional. FIG. 2 depicts anexemplary embodiment where each communication link or path isbidirectional (represented by double headed arrows).

Moreover, the local devices in the local infusion system may be capableof communication (unidirectional or bidirectional) with one or more“external” devices that are not considered to be part of the localinfusion system. The manner in which a given local device within thelocal infusion system communicates with a given external device may varydepending upon the particular configuration of the system 200, thecharacteristics of the local device, and the characteristics of theexternal device. For example, data may be routed between the localinfusion system and an external device using one data communicationnetwork, using a plurality of data communication networks, using adirect wireless or wired connection, or the like

As mentioned above, the system 200 includes or cooperates withcomputer-based and/or processor-based components having suitablyconfigured hardware and software written to perform the functions andmethods needed to support the features described herein. For example,the mobile device 204, the insulin infusion device 206, the bloodglucose meter 208 and the data uploader component 212 can be realized asan electronic processor-based component. An exemplary embodiment of adevice suitable for implementing the various components of the systemwill described below with reference to FIG. 3. In this regard, FIG. 3 isa simplified block diagram representation of an exemplary embodiment ofa computer-based or processor-based device 300 that is suitable fordeployment in the system shown in FIG. 2.

The illustrated embodiment of the device 300 is intended to be ahigh-level and generic representation of one suitable platform. In thisregard, any of the computer-based or processor-based components of thesystem 200 can utilize the architecture of the device 300. Theillustrated embodiment of the device 300 generally includes, withoutlimitation: at least one processor 302; a suitable amount of memory 304;device-specific hardware, software, firmware, and/or features 306; auser interface 308; a communication module 310; and a display element311. Of course, an implementation of the device 300 may includeadditional elements, components, modules, and functionality configuredto support various features that are unrelated to the subject matterdescribed here. For example, the device 300 may include certain featuresand elements to support conventional functions that might be related tothe particular implementation and deployment of the device 300. Inpractice, the elements of the device 300 may be coupled together via abus or any suitable interconnection architecture 301.

The processor 302 may be implemented or performed with a general-purposeprocessor, a content addressable memory, a digital signal processor, anapplication specific integrated circuit, a field programmable gatearray, any suitable programmable logic device, discrete gate ortransistor logic, discrete hardware components, or any combinationdesigned to perform the functions described here. Moreover, theprocessor 302 may be implemented as a combination of computing devices,e.g., a combination of a digital signal processor and a microprocessor,a plurality of microprocessors, one or more microprocessors inconjunction with a digital signal processor core, or any other suchconfiguration.

The memory 304 may be realized as RAM memory, flash memory, EPROMmemory, EEPROM memory, registers, a hard disk, a removable disk, aCD-ROM, or any other form of storage medium known in the art. In thisregard, the memory 304 can be coupled to the processor 302 such that theprocessor 302 can read information from, and write information to, thememory 304. In the alternative, the memory 304 may be integral to theprocessor 302. As an example, the processor 302 and the memory 304 mayreside in an ASIC. At least a portion of the memory 304 can be realizedas a computer storage medium, e.g., a tangible computer-readable mediumhaving computer-executable instructions stored thereon. Thecomputer-executable instructions, when read and executed by theprocessor 302, cause the device 300 to perform certain tasks,operations, functions, and processes that are specific to the particularembodiment. In this regard, the memory 304 may represent one suitableimplementation of such computer-readable media. Alternatively, oradditionally, the device 300 could receive and cooperate withcomputer-readable media (not separately shown) that is realized as aportable or mobile component or platform, e.g., a portable hard drive, aUSB flash drive, an optical disc, or the like.

The device-specific hardware, software, firmware, and features 306 mayvary from one embodiment of the device 300 to another. For example, thedevice-specific hardware, software, firmware, and features 306 willsupport: smartphone functions and features when the device 300 isrealized as a mobile telephone; conventional personal computer functionsand features if the device 300 is realized as a laptop or tabletcomputer; insulin pump operations when the device 300 is realized as aninsulin infusion device; etc. In practice, certain portions or aspectsof the device-specific hardware, software, firmware, and features 306may be implemented in one or more of the other blocks depicted in FIGS.3 and 4.

The user interface 308 may include or cooperate with various features toallow a user to interact with the device 300. Accordingly, the userinterface 308 may include various human-to-machine interfaces, e.g., akeypad, keys, a keyboard, buttons, switches, knobs, a touchpad, ajoystick, a pointing device, a virtual writing tablet, a touch screen, amicrophone, or any device, component, or function that enables the userto select options, input information, or otherwise control the operationof the device 300. The user interface 308 may include one or moregraphical user interface (GUI) control elements that enable a user tomanipulate or otherwise interact with an application via the displayelement 311.

The communication module 310 facilitates data communication between thedevice 300 and other components as needed during the operation of thedevice 300. In the context of this description, the communication module310 can be employed to transmit or stream device-related control data,patient-related data, device-related status or operational data,glycemic insight messages and notifications, and the like. It should beappreciated that the particular configuration and functionality of thecommunication module 310 can vary depending on the hardware platform andspecific implementation of the device 300. Accordingly, thecommunication module 310 is utilized to obtain input data from varioussources, and to send output data to other components or devices that aredescribed above with reference to FIGS. 1 and 2. In practice, anembodiment of the device 300 may support wireless data communicationand/or wired data communication, using various data communicationprotocols. For example, the communication module 310 could support oneor more wireless data communication protocols, techniques, ormethodologies, including, without limitation: RF; IrDA (infrared);Bluetooth®; ZigBee® (and other variants of the IEEE 802.15 protocol);IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation);Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum;cellular/wireless/cordless telecommunication protocols; wireless homenetwork communication protocols; paging network protocols; magneticinduction; satellite data communication protocols; wireless hospital orhealth care facility network protocols such as those operating in theWMTS bands; GPRS; and proprietary wireless data communication protocolssuch as variants of Wireless USB. Moreover, the communication module 310could support one or more wired/cabled data communication protocols,including, without limitation: Ethernet; powerline; home networkcommunication protocols; USB; IEEE 2394 (Firewire); hospital networkcommunication protocols; and proprietary data communication protocols.In one particular implementation, the communication module 310 includesa far-field communication module and a body area network communicationmodule, and a controller (not illustrated).

The far-field communication module includes various far-fieldcommunication interfaces that can be used to communicate electromagneticsignals to other devices that are part of a body area network. In thisnon-limiting example, various far-field communication interfaces caninclude, but are not limited to, a Bluetooth low energy (BLE®)communication interface, a classical Bluetooth® (BT) communicationinterface, a wireless local area network (WLAN) communication interface(e.g., a Wi-Fi interface), and a cellular communication interface. Theabove-mentioned communication interfaces can comply with any knownstandards. For example, the BLE® communication interface can communicatein compliance with any Bluetooth® release (e.g., versions 1.0 through5.1), and any physical (PHY) layer specifications defined therein. Forinstance, Bluetooth® 5.0 includes three PHY layer variations called LE1M, LE 2M and LE Coded. Each PHY variant has its own particularcharacteristics and was designed with specific aims in mind. As anothernon-limiting example, the BLE® communication interface can communicatein compliance with a Bluetooth® mesh networking protocol (defined inMesh Profile Specification and Mesh Model Specification which wasadopted on Jul. 13, 2017). The Bluetooth® mesh networking protocol is aprotocol based upon Bluetooth Low Energy® that allows for many-to-manycommunication over Bluetooth® radio.

When a signal from a far-field communication interface is transmitted byan antenna, it is attenuated over distance to the point that the signalcannot be effectively detected. This is called far-field transmission,and works well if the signal needs to be transmitted over a longdistance. However, far-field communication interfaces can have problemsif the wireless communication needs to be very low power and confines toa fairly short distance near body areas. Improper placement of devicesclose to a human body may result in a detuned antenna input impedance,reduced antenna efficiency, and distorted antenna radiation pattern.Penetration of electromagnetic signals generated by far-fieldcommunication interfaces into the human body is another problem becauseelectromagnetic signals can be quickly absorbed and greatly attenuateddue to the very conductive body tissues. In addition, interference canbe very high due to coexistence of multiple far-field communicationinterfaces (e.g., BT, BLE®, Wi-Fi, and ZigBee®) that operate in the samefrequency band. Power consumption can also limit continuous operation.Lastly, far-field communication interface can present potential securityproblems because electromagnetic signals can be intercepted anddecrypted after propagating into free space.

On the other hand, the body area network communication module includesvarious near-field communication interfaces that can be used tocommunicate magnetic signals to other devices that are part of a bodyarea network. In this non-limiting example, various near-fieldcommunication interfaces can include, but are not limited to, a nearfield magnetic inductive (NFMI) radio communication interface, anear-field electromagnetic induction (NFeMI) radio communicationinterface (not illustrated), a near field communication (NFC) interface,an RFID high-frequency (HF) communication interface, and one or more lowpower wide area network (LPWAN) communication interfaces. A near-fieldcommunication interface can provide a more reliable, a more secure, anda much lower power radio link within, on, and in the immediate proximityof a human body.

For example, NFMI is a short-range wireless technology that communicatesusing a tightly coupled magnetic field among devices. NFMI enables humanbody friendly, reliable, secure, and power efficient wirelesscommunication. As used herein, the term “Near-Field Magnetic Induction(NFMI) radio communication system” can refer to a short range wirelessphysical layer that communicates by coupling a tight, low-power,non-propagating magnetic field between devices. A transmitter coil inone device can modulate a magnetic field which is measured by a receivercoil in another device. To explain further, in NFMI-based communicationsystems, a modulated signal that is sent out from a transmitter coil isin the form of a magnetic field. This magnetic field induces voltage onthe receiving coil, which in turn will be measured by an NFMI receiver.NFMI radio communication systems differ from other wirelesscommunications in that most conventional wireless RF systems use anantenna to generate, transmit, and propagate an electromagnetic wave,where all of the transmission energy is designed to radiate into freespace. This type of transmission is referred to as “far-field.” NFMIsystems are designed to contain transmission energy within the localizedmagnetic field. This magnetic field energy resonates around thecommunication system, but does not radiate into free space. To explainfurther, the power density of NFMI signals attenuate at a rate inverselyproportional to the distance to the sixth power compared to the secondpower for Bluetooth® signals. This means for the same distance, thepower density of NFMI signals is 10000 times weaker than Bluetooth®signals provided that both transmitting power are equal. This type ofwireless transmission is referred to as “near-field.” Various modulationschemes used in typical RF communications (e.g., amplitude modulation,phase modulation, and frequency modulation) can also be used innear-field magnetic induction communication system.

As used herein, the term “near-field electromagnetic induction (NFeMI)radio communication interface” can refer to a communication interfacethat can operate near a human body by means of a combination of amagnetic field and electric field without the use of transversalradiating waves. Such NFEMI systems improve a wearable device's signallink budget and extend their range to a complete human body. Whereas RFwireless communication may be accomplished by propagating an RF planewave through free space, NFEMI communication utilizes non-propagatingquasi-static fields.

As used herein, the term “Near-field communication (NFC)” can refer to aset of communication protocols and data exchange formats that enable twoor more electronic devices (e.g., a medical device such as an insulinpump and a portable device such as a smartphone) to establishcommunication with each other by bringing them within a short separationrange of each other (e.g., 2 meters or less). NFC allows one- andtwo-way communication between endpoints, suitable for many applications.NFC uses electromagnetic induction between two loop antennas (locatedwithin each other's near-field) to effectively form an air-coretransformer that allows them to exchange information. The NFC interfaceoperates based on similar principles as the NFMI interface 322 and usesthe same high-frequency (HF) band. However, NFMI extends the range ofNFC (e.g., from a distance of 1-4 inches for NFC, to up to 9 feet forNFMI). At around 13 MHz, NFMI provides a data rate of over 400 Kbps perfrequency channel, up to 10 separate frequency channels and 10sub-channels per frequency channel using time division (e.g., a hundredseparate wireless links inside a single WBAN). In one non-limitingimplementation, NFC-enabled devices that are described herein canexchange information in accordance with any NFC standards that covercommunications protocols and data exchange formats. NFC standards covercommunications protocols and data exchange formats and are based onexisting radio-frequency identification (RFID) standards includingISO/IEC 14443. The standards include ISO/IEC 18092 and those defined bythe NFC Forum. In addition to the NFC Forum, the GSM Association (GSMA)group defined a platform for the deployment of GSMA NFC Standards withinmobile handsets.

RFID systems can operate in low frequency (LF), high frequency (HF), andultra-high frequency (UHF) bands, and thus can be categorized by thefrequency band within which they operate: low frequency, high frequency,and ultra-high frequency. In addition, there are also two broadcategories of systems—passive and active RFID. The LF band coversfrequencies from 30 KHz to 300 KHz (e.g., some LF RFID systems operateat 125 KHz, while others operate at 134 KHz). The RFID HF communicationinterface 326 can operate in a HF band that ranges from 3 to 30 MHz,with communications ranges between 10 cm and 1 m. There are several HFRFID standards, such as the ISO 15693 standard for tracking items, andthe ECMA-340 and ISO/IEC 18092 standards for Near Field Communication(NFC), the ISO/IEC 14443 A and ISO/IEC 14443 standards. The UHFfrequency band covers the range from 300 MHz to 3 GHz, and the range ofsome UHF systems can be as long as 12 m with faster data transfer ratesthan LF or HF. The UHF frequency band is regulated by a single globalstandard called the ECPglobal Gen2 (ISO 18000-63) UHF standard.

The low power wide area network (LPWAN) communication interfaces caninclude interfaces such as a Long Term Evolution for Machines (LTE-M)communication interface (LTE-Cat M1) and/or a narrowband-IoT (NB-IoT)communication interface (not illustrated). NB-IOT and LTE-M are twonewer low power wide area (LPWA) technologies that were developed forIOT applications. Both are protocols for low bandwidth cellularcommunications that connect to the internet devices that need totransmit small amounts of data, with the lower costs (both hardware andsubscription) and the higher battery life.

The various communication interfaces mentioned above are non-limiting,and can be implemented in accordance with any known standards includingthose mentioned above. However, it should be appreciated that the numberof communication interfaces that are included as part of thecommunication module 310 can vary depending on the implementation.

A controller (not illustrated) can be configured to control which onesof the communication interfaces are selected and used by a device orcomponent of the wireless body area network to communicate data withother devices or components that are part of the wireless body areanetwork. For example, the controller is configured to select which oneof the communication interfaces is to be used at any particular time andswitch between which one of the communication interfaces is enabled andused by a device or component of the wireless body area network tocommunicate data with other devices or components that are part of thewireless body area network.

As will be described in greater detail below, depending on a device'sproximity to the body area network, the controller can select any of thevarious communication interfaces to use for communications with otherdevices that are part of the body area network. The controller canseamlessly switch between the various communication interfaces based onfactors such as quality of service of the communication link withanother device, the security type of the data that is being communicatedto the other device, etc. In this regard quality of service can bemeasured using any standard quality of service performance metrics(e.g., RSSI, packet loss, packet error rate (PER), bit rate, bit errorrate, latency, throughput, transmission delay, availability, jitter,etc.) and compared to a threshold. Quality of service metrics can alsoinclude metrics such as service response time, loss, signal-to-noiseratio, crosstalk, echo, interrupts, frequency response, and so on.Quality of service (QoS) is the description or measurement of theoverall performance of a service, particularly the performance seen bythe users of the network.

When the quality of service is greater than or equal to the threshold,the device can utilize a particular communication interface. When thequality of services is less than the threshold, the controller can thendetermine an appropriate communication interface to switch to that willachieve the desired quality of service that is greater than or equal tothe threshold. In addition, in some embodiments, once the controllerdetermines that the quality of service over one of the communicationinterfaces is greater than or equal to the threshold, the controller canalso determine the type of data that is being communicated by thedevice, and if it is a high security datatype, the controller can alsorestrict communication to one of the body area network communicationinterfaces such that communications can only take place within traceablesecurity boundary, as defined by the body area network, where thewireless energy has not degraded to a negligible level. In other words,when the type of data being communicated is a high security datatype,the controller will only utilize one of the body area networkcommunication interfaces to help ensure security of the data that'sbeing communicated.

Referring again to FIG. 3, the display element 311 is suitablyconfigured to enable the device 300 to render and display variousscreens, insight messages, notifications, GUIs, GUI control elements,drop down menus, auto-fill fields, text entry fields, message fields, orthe like. Of course, the display element 311 may also be utilized forthe display of other information during the operation of the device 300,as is well understood. Notably, the specific configuration, operatingcharacteristics, size, resolution, and functionality of the displayelement 310 can vary depending upon the practical implementation of thedevice 300. For example, if the device 300 is a laptop computer, thenthe display element 311 may be a relatively large monitor.Alternatively, if the device 300 is a cellular telephone device (e.g.,smartphone), then the display element 311 may be a relatively smallintegrated display screen, such as a touch-sensitive screen.

FIG. 4 is a method 400 for verifying whether a communication linkbetween a non-medical client device 108 and a medical device 102, 104 isestablished and for causing a notification to be issued at thenon-medical client device 108 and/or the medical device 102, 104 whenthe communication link is not established in accordance with thedisclosed embodiments. As a preliminary matter, it should be understoodthat the steps of the method 400 are not necessarily limiting. Withreference to method 400, steps can be added, omitted, and/or performedsimultaneously without departing from the scope of the appended claims.It should be appreciated that the method 400 may include any number ofadditional or alternative tasks, that the tasks shown in FIG. 4 need notbe performed in the illustrated order, and that the method 400 may beincorporated into a more comprehensive procedure or process havingadditional functionality not described in detail herein. Moreover, oneor more of the tasks shown in FIG. 4 could potentially be omitted froman embodiment of the method 400 as long as the intended overallfunctionality remains intact. It should also be understood that theillustrated method 400 can be stopped at any time. The method 400 iscomputer-implemented in that various tasks or steps that are performedin connection with the method 400 may be performed by software,hardware, firmware, or any combination thereof. For illustrativepurposes, the following description of the method 400 may refer toelements mentioned above in connection with FIGS. 1-3.

In certain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium. For instance, in the description of FIG. 4that follows, the non-medical client device 108 and the medical device102, 104 will be described as performing various acts, tasks or steps,but it should be appreciated that this refers to processing system(s) ofthese entities executing instructions to perform those various acts,tasks or steps. Depending on the implementation, the method 400 can beperformed by an application at the non-medical client device 108 and/oran application at the medical device 102, 104 to regularly check thestatus of the communication link between the non-medical client device108 and the medical device 102, 104 to make sure that the respectivemedical control applications at each are able to communicate. Therapyrelated notifications can be generated from the medical device 102, 104.Both the medical device 102, 104 and the non-medical client device 108are capable of confirming communication link between them and notifyingthe user if the communication link is not there. If the communicationlink between the non-medical client device 108 and the medical device102, 104 is not adequate (e.g., not established), one or morenotifications, warnings, alerts or alarms on the medical device 102, 104can be activated to alert the user that the communication link betweenthe non-medical client device 108 and the medical device 102, 104 isinadequate. As described above, the notifications, warnings, alerts oralarms on the medical device 102, 104 can be, for example, visual,haptic and/or audio alarms. In some embodiments, the visual, hapticand/or audio alarms can be implemented in specific sequences of visual,audio and haptics for different messages. For example, three flashes orvibration followed by a pause to indicate loss of communication withnon-medical client device 108. Furthermore, in the description of FIG.4, a particular example is described in which the non-medical clientdevice 108 and/or the medical device 102, 104 perform certain actions byinteracting with other elements of the system described above withreference to FIGS. 1-3.

The communication link verification method 400 begins at 402, where thelink verification process starts and the method 400 proceeds to 404. At404, an application determines whether a trigger event has occurred. Thetrigger event could be, for example, receiving an indication that analert has been issued or needs to be acknowledged; receiving anindication that a notification, alarm, alert, or warning needs to beactivated; receiving an indication that a link verification timer hasexpired; receiving an indication that a link verification counter has acount greater than or equal to a threshold count; receiving that aregularly scheduled data transfer (e.g., blood glucose or confirmationof last insulin delivery) did not occur, etc. The method 400 loops at404 until a trigger event occurs and then proceeds to 406.

At 406, the application determines whether the communication linkbetween the non-medical client device 108 and the medical device 102,104 is established or adequate (e.g., whether the medical controlapplication 107 that is running on the non-medical client device 108 isable to communicate with the medical control application 105 that isrunning at the medical device 102, 104). When the application determines(at 406) that an adequate communication link is established betweencommunication interfaces of the non-medical client device 108 and themedical device 102, 104, the method 400 loops back to 402. In oneembodiment, a timer or counter can be reset when it is determined (at406) that the non-medical client device 108 and the medical device 102,104 have an adequate communication link.

When the application determines (at 406) that the that the communicationlink is inadequate, the method 400 proceeds to 408 where the applicationat either the non-medical client device 108 or the medical device 102,104 attempts to establish (or reestablish) a communication link betweencommunication interfaces of the medical device 102, 104 and thenon-medical client device 108. The method 400 then proceeds to 410,where the application determines whether the communication link wassuccessfully established. When the application determines (at 410) thatthe communication link was successfully established, the method 400loops back to 402.

When the application determines (at 410) that the communication link wasnot successfully established, the method 400 proceeds to 412, where theapplication at the non-medical client device 108, and/or the applicationat the medical device 102, 104, causes one or more notifications,warnings, alarms or alerts to be activated at the non-medical clientdevice 108, and/or the medical device 102, 104 causes one or morenotifications, warnings, alarms or alerts to be activated at the medicaldevice 102, 104. Since the non-medical client device 108 may beseparated from the patient, the medical device 102, 104 should be ableperform the check and if needed issue a notification. Having thenon-medical client device 108 in the system may be critical insituations where the system is programmed to also notify the caregiversor health care providers thru the cloud.

FIG. 5 is a method 500 for verifying that a non-medical client deviceand a medical control application are operating/functioning properly inaccordance with the disclosed embodiments. As a preliminary matter, itshould be understood that the steps of the method 500 are notnecessarily limiting. With reference to method 500, steps can be added,omitted, and/or performed simultaneously without departing from thescope of the appended claims. It should be appreciated that the method500 may include any number of additional or alternative tasks, that thetasks shown in FIG. 5 need not be performed in the illustrated order,and that the method 500 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein. Moreover, one or more of the tasks shown in FIG. 5 couldpotentially be omitted from an embodiment of the method 500 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 500 can be stopped at any time.The method 500 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 500 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 500 mayrefer to elements mentioned above in connection with FIGS. 1-3.

In certain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium. For instance, in the description of FIG. 5that follows, the non-medical client device 108 and the medical device102, 104 will be described as performing various acts, tasks or steps,but it should be appreciated that this refers to processing system(s) ofthese entities executing instructions to perform those various acts,tasks or steps. Depending on the implementation, the method 500 can beperformed by an application at the non-medical client device 108 and/orat the medical device 102, 104. In one embodiment, the method 500 can beinitiated by the non-medical client device 108 to execute one or morediagnostic checks to ensure the medical control application at thenon-medical client device 108 is running properly and has access torequired resources for its proper function. The method 500 can be usedto generate a notification at the non-medical client device 108 to alertthe user when medical control application 107 of the non-medical clientdevice 108 is not operating/functioning properly (e.g., not runningproperly or does not have access to required resources for it tofunction properly). Furthermore, in the description of FIG. 5, aparticular example is described in which the non-medical client device108 and/or the medical device 102, 104 perform certain actions byinteracting with other elements of the system described above withreference to FIGS. 1-3.

The method 500 starts at 502, the application starts an applicationverification process. At 504, the application monitors for a triggerevent by determining whether a trigger event has occurred. The triggerevent could be, for example, receiving an indication that an alert hasbeen issued or needs to be acknowledged; receiving an indication that anotification, alarm, alert, or warning needs to be activated; receivingan indication that an application verification timer has expired;receiving an indication that an application verification counter has acount greater than or equal to a threshold count; receiving anindication or discovering that a communication link between the medicaldevice and non-medical device is not operating or communicating asintended, etc. The method 500 loops at 504 until a trigger event occursand then proceeds to 506.

When a trigger event has been determined to have occurred (at 504), theapplication initiates an application verification protocol at 506 toverify whether the application is operating/functioning properly and/orhas access to required computing resources. The application verificationprotocol can include running one or more diagnostic checks. Thediagnostic checks can be used to verify that the application isoperating/functioning properly and/or has access to required computingresources.

The diagnostic checks that are performed or executed at 506 can include:verifying whether a communication link between a non-medical clientdevice 108 and a medical device 102, 104 is established (as describedabove with reference to FIG. 4); determining whether the applicationand/or the operating system version is up-to-date and/or authentic;determining whether the settings of the application are correct;determining whether the application is loading properly; determiningwhether the application is running properly; determining whether theapplication has access to adequate computing resources (e.g., processingresources, communication resources, user interface resources, and/ormemory resources) of the device; determining whether the application hasaccess to adequate computing resources of the non-medical client device108 (e.g., processing resources, communication resources, user interfaceresources, and/or memory resources) of the device, etc. For instance,the medical device 102, 104 should be satisfied that the application isworking properly and has access to resources such as processor, memory,speakers, camera flash, display, haptic or other vibrators, or othermeans for generating notifications, etc. If the medical device 102, 104does have confirmation of this is should notify the user thru its ownnotification means. The number of diagnostic checks that are performed,and the order in which they are performed, can vary depending on theimplementation.

In one embodiment, the diagnostic checks can be performed in parallel orsimultaneously or nearly simultaneously. In another embodiment, thediagnostic checks can be performed sequentially (in a predeterminedorder). For instance, after initiation of the application verificationprotocol at 506, steps 506 through 512 are iteratively performed to runa series of diagnostic checks that are used to determine whether theapplication is running or operating/functioning properly and/or hasaccess to required computing resources. On the first iteration of 506,the first diagnostic check is executed. At 508, the applicationdetermines whether the application passed the first diagnostic check,and if so, the method 500 proceeds to 512, where the applicationdetermines whether there are any additional diagnostic checks to beexecuted. If it is determined (at 512) that there are no additionaldiagnostic checks to be executed, the method 500 proceeds to 514. Whenit is determined (at 512) that there are additional diagnostic checks tobe executed, the method 500 loops back to 506, where the applicationexecutes the next diagnostic check to determine whether the applicationis operating/functioning properly and/or has access to requiredcomputing resources. In one embodiment, steps 506 through 512 loop untilall the diagnostic checks have been executed.

Whenever the application determines at 508 that the application did notpass a particular diagnostic check that was executed (at 506), themethod 500 can proceed to 510 where a problem corresponding to thatparticular diagnostic check is logged to create a record that explainswhy the application is not operating/functioning properly and/or doesnot have access to required computing resources, and the method thenproceeds to 512. When it is determined (at 512) that there are noadditional diagnostic checks to be executed, the method 500 proceeds to514.

At 514, the application attempts to initiate one or more remedialcorrection measures in an attempt to correct issues that are causing itto run improperly so that the application will function correctly and/orhave access to required computing resources. The remedial correctionmeasures that are taken (at 514) can vary depending on theimplementation and which diagnostic checks were performed or executed at506, and which ones of those were determined to have not passed (NO at508). The remedial correction measures that are taken (at 514) caninclude, for example: automatically closing and restarting theapplication; prompting the user to change restart the application of thenon-medical client device when it is determined that the application isnot loading or is not running properly; automatically powering thedevice off, restarting it and reopening the application; downloading andinstalling an up-to-date version of the application or the operatingsystem when it is determined that the existing versions were not correct(e.g., no up-to-date and/or authentic); prompting the user to change oneor more settings of the application when it is determined that one ormore settings of the application are incorrect; freeing up additionalcomputing resources for use by the application when it is determinedthat the application does not have access to adequate computingresources; changing a setting at the non-medical client device 108(e.g., changing a setting via the operating system of the non-medicalclient device 108), etc.

Each time one of the remedial correction measures is initiated (at 514),the method 500 determines at 516 whether that correction measure wassuccessful. Whenever any one of the remedial correction measures isdetermined (at 516) to have not been successful, this means that theapplication is not running properly and/or does not have access torequired computing resources, and the method 500 can proceed to 518where the application causes a notification (e.g., an alert, alarm orother warning signal) to be generated at the non-medical client deviceand/or at the medical device 102, 104. For example, an alert ornotification could be issued at the infusion device 102. Alerts ornotifications can be issued until the medical device 102, 104 issatisfied that the non-medical client device 108 and its correspondingapplication are working properly (e.g., able to communicate with themedical device 102, 104, issue notifications, etc.) In addition, in someembodiments, at 520, the non-medical client device 108 can present(e.g., via a display) suggestions to the user to suggest changes tosettings on the non-medical client device 108 to correct the problem.For instance, the non-medical client device 108 can display suggestedchanges to notification settings, allow access to location data,activity data, a microphone of the non-medical client device 108, orprovide shortcuts or links to settings that need to be changed. If themedical device 102, 104 fails, the non-medical client device 108 maysuggest actions based last uploaded data such as insulin on board, lastbolus, BG, etc. The suggestions may include instructions on how to usean insulin pen or syringe until the pump can be replaced. Thenon-medical client device 108 can also send notifications to care giveror health care provided (HCP).

When it is determined that each of the correction measures that wereexecuted (at 514) were successful, this means that the application isrunning properly and/or has access to required computing resources, andthe method 500 loops back to 504.

FIG. 6 is a method 600 for generating a notification (alarms, alert orother warning signal) at a medical device 102, 104 when a notificationgenerated at a non-medical client device 108 is not acknowledged inaccordance with the disclosed embodiments. As a preliminary matter, itshould be understood that the steps of the method 600 are notnecessarily limiting. With reference to method 600, steps can be added,omitted, and/or performed simultaneously without departing from thescope of the appended claims. It should be appreciated that the method600 may include any number of additional or alternative tasks, that thetasks shown in FIG. 6 need not be performed in the illustrated order,and that the method 600 may be incorporated into a more comprehensiveprocedure or process having additional functionality not described indetail herein. Moreover, one or more of the tasks shown in FIG. 6 couldpotentially be omitted from an embodiment of the method 600 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 600 can be stopped at any time.The method 600 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 600 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 600 mayrefer to elements mentioned above in connection with FIGS. 1-3.

In certain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium. For instance, in the description of FIG. 6that follows, the non-medical client device 108 and the medical device102, 104 will be described as performing various acts, tasks or steps,but it should be appreciated that this refers to processing system(s) ofthese entities executing instructions to perform those various acts,tasks or steps. The method 600 can be performed by applications at thenon-medical client device 108 and at the medical device 102, 104. Themethod 600 can be used to generate a therapy-related notifications(e.g., a haptic signal, a visual signal and/or the audio signal) at themedical device 102, 104 to alert the user when alarms or alertsgenerated at the non-medical client device 108 are not acknowledgedwithin a predetermined time threshold. Furthermore, in the descriptionof FIG. 6, a particular example is described in which the non-medicalclient device 108 and/or the medical device 102, 104 perform certainactions by interacting with other elements of the system described abovewith reference to FIGS. 1-3.

To explain further, the method 600 begins at 602 (which can be step 518of FIG. 5) when a notification (alarm, alert, or other warning signal)is generated at the user's non-medical client device. The method 600then proceeds to 604, where an application at the non-medical clientdevice 108 starts a counter for an alert escalation process, and themethod then proceeds to 606. At 606, an application at the non-medicalclient device 108 determines whether the notification (generated at 602)at the non-medical client device 108 was acknowledged within a certaintime frame. When it is determined that the notification (generated at602) at the non-medical client device 108 was acknowledged within acertain time frame, the method 600 proceeds to 608 where the method 600ends. When it is determined that the notification (generated at 602) atthe non-medical client device 108 was not acknowledged within a certaintime frame, the method 600 proceeds to 610.

At 610, the application at the non-medical client device 108 determineswhether counter for the alert escalation process it greater than orequal to a threshold count. The process at 610 loops back to 606 untilthe counter for the alert escalation process is determined (at 610) tobe equal to the threshold count. In other words, when the applicationdetermines (at 610) that the counter has not yet reached the threshold(e.g., count of the counter is less than the threshold), the method 600loops back to 606.

When the counter for the alert escalation process is determined (at 610)to be equal to the threshold count, the method 600 proceeds to 612,where the application causes a notification (e.g., an alarm or alert) tobe generated at the medical device 102, 104. In one embodiment, themedical control application 105 at the medical device 102, 104 causes anotification (e.g., an alert or alarm such as a haptic signal, visualsignal and/or audio signal) to be generated at the medical device 102,104. In one embodiment, the application can also activate haptics,camera flash, override silent mode, and increase speaker or alarm volumeat the non-medical client device 108 if user does not acknowledge anotification. The method 600 proceeds to 614, where the method 600 ends.The notification is used to alert the user that notifications generatedat the non-medical client device 108 have not been acknowledged so thatthe user can then take remedial measures at the non-medical clientdevice 108 so that the application of the non-medical client device 108is operating/functioning properly.

Thus, the medical device 102, 104 should initiate system checks for thenon-medical client device 108. If the non-medical client device 108 isnot functioning properly and cannot be fixed automatically or by thepatient, notifications thru non-medical client device 108 should begenerated. If notification is not acknowledged by patient on non-medicalclient device 108 then medical device 102, 104 should notify thepatient. When notifications generated by medical device 102, 104 are notgenerated at the non-medical client device 108 (due to issues at thenon-medical client device 108), the application 107 at the non-medicalclient device 108 can confirm whether the notifications have beenacknowledged and send a confirmation to medical device 102, 104. If thenon-medical client device 108 cannot confirm that a notification wasissued, it should try to correct by checking settings to see if it hasaccess to resources (speakers, haptics, etc.), and if not suggestcorrective action. If corrective action is not successful, then anotification at can be generated at one or more of the medical devices102, 104. The medical device 102, 104 can notify the user ifacknowledgement from the non-medical client device 108 is not receivedwithin a reasonable time that can vary depending on criticality ofnotification. For example, an alert time to do a blood glucose checkissued from medical device 102, 104 may allow more time for thenon-medical client device 108 to come back with an acknowledgment orcorrect an issue. For critical alarms such as an occlusion in line, theallowed time can be shorter.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application.

What is claimed is:
 1. A method for verifying whether a non-medicalclient device is operating correctly with a medical device controlled bythe non-medical client device and causing a notification to begenerated, the method comprising: monitoring for occurrence of a triggerevent via an application at the non-medical client device; performing,via the application at the non-medical client device when theapplication at the non-medical client device detects occurrence of thetrigger event, one or more diagnostic checks to verify whether a medicalcontrol application at the non-medical client device is operatingcorrectly; attempting to initiate one or more remedial correctionmeasures to restore the medical control application at the non-medicalclient device so that it is operating correctly when the application atthe non-medical client device determines that the one or more diagnosticchecks have failed; and causing, via the application at the non-medicalclient device, the notification to be generated via a user interface ofthe non-medical client device when the one or more remedial correctionmeasures were unsuccessful.
 2. The method of claim 1, wherein thenotification is a first notification, and further comprising: starting acounter at the non-medical client device after causing the firstnotification to be generated via the user interface of the non-medicalclient device; regularly determining, via the application at thenon-medical client device, whether an acknowledgement signal wasgenerated to acknowledge the first notification; and causing a secondnotification to be generated via a second user interface of the medicaldevice when a count of the counter exceeds a threshold count and noacknowledgement signal was generated to acknowledge the firstnotification, wherein the second notification is used to alert a userthat the first notification generated at the non-medical client devicehas not been acknowledged so that other remedial measures can be takenat the non-medical client device.
 3. The method of claim 1, whereinperforming comprises: performing a communication link verificationprocess, via the application at the non-medical client device when theapplication at the non-medical client device detects occurrence of thetrigger event, to determine whether the non-medical client device has anestablished communication link to the medical device.
 4. The method ofclaim 3, wherein attempting comprises: attempting to establish acommunication link between the non-medical client device and the medicaldevice when the application at the non-medical client device determinesthat the non-medical client device does not haves a communication linkto the medical device.
 5. The method of claim 4, wherein causingcomprises: causing a first notification to be generated via the userinterface of the non-medical client device when the attempt to establishthe communication link between the non-medical client device and themedical device is unsuccessful; and causing a second notification to begenerated via a second user interface of the medical device when theattempt to establish the communication link between the non-medicalclient device and the medical device is unsuccessful.
 6. The method ofclaim 1, wherein performing comprises: initiating a verificationprotocol, via the application at the non-medical client device when theapplication at the non-medical client device detects occurrence of thetrigger event, wherein the verification protocol comprises: executingone or more diagnostic checks to verify whether the medical controlapplication is functioning properly and has access to adequate computingresources, wherein the computing resources include processing resources,communication resources, user interface resources, and memory resources.7. The method of claim 1, wherein the trigger event comprises one ormore of: receiving an indication that a notification needs to beacknowledged; receiving an indication that a notification needs to beactivated; receiving an indication that a notification has been issued;receiving an indication that a timer has expired; and receiving anindication that a counter has a count that exceeds a threshold count. 8.The method of claim 1, wherein the one or more diagnostic checks toverify whether the medical control application is operating correctlycomprise one or more of: determining whether an operating system versionis up to date; determining whether the medical control application is upto date; determining whether settings of the medical control applicationare correct; determining whether the medical control application isloading properly; and determining whether the medical controlapplication is running properly.
 9. The method of claim 1, wherein theone or more remedial correction measures attempt to correct issues thatare causing the non-medical client device to run improperly so that themedical control application will function correctly and have access torequired computing resources.
 10. The method of claim 1, wherein the oneor more remedial correction measures comprise one or more of:automatically closing and restarting the medical control application;prompting the user to change restart the medical control application ofthe non-medical client device when it is determined that the medicalcontrol application is not loading or is not running properly;automatically powering the non-medical client device off, automaticallyrestarting non-medical client device and reopening the medical controlapplication; downloading and installing an up-to-date version of themedical control application or an up-to-date version of an operatingsystem when it is determined that the existing versions were notcorrect; prompting the user to change one or more settings of themedical control application when it is determined that one or moresettings of the medical control application are incorrect; and freeingup additional computing resources of the non-medical client device foruse by the medical control application when it is determined that themedical control application does not have access to adequate computingresources.
 11. The method of claim 1, wherein the non-medical clientdevice comprises: a smartphone, and wherein the medical device comprisesone of an insulin infusion device that is configured to be controlledvia the medical control application executed at the smartphone, and aglucose sensor arrangement.
 12. A non-medical client device that isconfigured to execute a medical control application that controls amedical device, the non-medical client device comprising: at least oneprocessor device; and a non-transitory processor-readable mediumoperatively associated with the at least one processor device, theprocessor-readable medium comprising executable instructionsconfigurable to cause the at least one processor device to perform amethod for verifying whether the non-medical client device is operatingcorrectly with the medical device and causing a notification to begenerated, the method comprising: monitoring for occurrence of a triggerevent via an application at the non-medical client device; performing,via the application at the non-medical client device when theapplication at the non-medical client device detects occurrence of thetrigger event, one or more diagnostic checks to verify whether a medicalcontrol application at the non-medical client device is operatingcorrectly; attempting to initiate one or more remedial correctionmeasures via the application to restore the medical control applicationat the non-medical client device so that it is operating correctly whenthe application at the non-medical client device determines that the oneor more diagnostic checks have failed; and causing, via the applicationat the non-medical client device, the notification to be generated via auser interface of the non-medical client device when the one or moreremedial correction measures were unsuccessful.
 13. The non-medicalclient device of claim 12, wherein the notification is a firstnotification, and the method further comprising: starting a counter atthe non-medical client device after causing the first notification to begenerated via the user interface of the non-medical client device;regularly determining, via the application at the non-medical clientdevice, whether an acknowledgement signal was generated to acknowledgethe first notification; and causing a second notification to begenerated via a second user interface of the medical device when a countof the counter exceeds a threshold count and no acknowledgement signalwas generated to acknowledge the first notification, wherein the secondnotification is used to alert a user that the first notificationgenerated at the non-medical client device has not been acknowledged sothat other remedial measures can be taken at the non-medical clientdevice.
 14. The non-medical client device of claim 12, whereinperforming comprises: initiating a verification protocol, via theapplication at the non-medical client device when the application at thenon-medical client device detects occurrence of the trigger event,wherein the verification protocol comprises: executing one or morediagnostic checks to verify whether the medical control application isfunctioning properly and has access to adequate computing resources,wherein the computing resources include processing resources,communication resources, user interface resources, and memory resources.15. The non-medical client device of claim 12, wherein the one or moreremedial correction measures attempt to correct issues that are causingthe non-medical client device to run improperly so that the medicalcontrol application will function correctly and have access to requiredcomputing resources, and wherein the one or more remedial correctionmeasures comprise one or more of: automatically closing and restartingthe medical control application; prompting the user to change restart atleast one of the medical control application, the non-medical clientdevice and an operating system of the non-medical client device when itis determined that the medical control application is not loading or isnot running properly; automatically powering the non-medical clientdevice off, automatically restarting non-medical client device andreopening the medical control application; downloading and installing anup-to-date version of the medical control application or an up-to-dateversion of an operating system when it is determined that the existingversions were not correct; prompting the user to change one or moresettings of the medical control application when it is determined thatone or more settings of the medical control application are incorrect;and freeing up additional computing resources of the non-medical clientdevice for use by the medical control application when it is determinedthat the medical control application does not have access to adequatecomputing resources.
 16. A wireless body area network for an insulininfusion system, comprising: a plurality of devices that are part of thewireless body area network, the plurality of devices comprising: anon-medical client device and a medical device configured to becontrolled by a medical control application executed by the non-medicalclient device, the non-medical client device comprising: a processordevice; and a non-transitory processor-readable medium operativelyassociated with the processor device, the processor-readable mediumcomprising executable instructions configurable to cause the processordevice to perform a method for verifying whether the non-medical clientdevice is operating correctly with the medical device and causing anotification to be generated, the method comprising: monitoring foroccurrence of a trigger event via an application at the non-medicalclient device; performing, via the application at the non-medical clientdevice when the application at the non-medical client device detectsoccurrence of the trigger event, one or more diagnostic checks to verifywhether a medical control application at the non-medical client deviceis operating correctly; attempting to initiate one or more remedialcorrection measures via the application to restore the medical controlapplication at the non-medical client device so that it is operatingcorrectly when the application at the non-medical client devicedetermines that the one or more diagnostic checks have failed; andcausing, via the application at the non-medical client device, thenotification to be generated via a user interface of the non-medicalclient device when the one or more remedial correction measures wereunsuccessful.
 17. The wireless body area network of claim 16, whereinthe notification is a first notification, and the method furthercomprising: starting a counter at the non-medical client device aftercausing the first notification to be generated via the user interface ofthe non-medical client device; regularly determining, via theapplication at the non-medical client device, whether an acknowledgementsignal was generated to acknowledge the first notification; and causinga second notification to be generated via a second user interface of themedical device when a count of the counter exceeds a threshold count andno acknowledgement signal was generated to acknowledge the firstnotification, wherein the second notification is used to alert a userthat the first notification generated at the non-medical client devicehas not been acknowledged so that other remedial measures can be takenat the non-medical client device.
 18. The wireless body area network ofclaim 16, wherein the trigger event comprises one or more of: receivingan indication that a notification needs to be acknowledged; receiving anindication that a notification needs to be activated; receiving anindication that a notification has been issued; receiving an indicationthat a timer has expired; and receiving an indication that a counter hasa count that exceeds a threshold count, and wherein the one or morediagnostic checks to verify whether the medical control application isoperating correctly comprise one or more of: determining whether anoperating system version is up to date; determining whether the medicalcontrol application is up to date; determining whether settings of themedical control application are correct; determining whether the medicalcontrol application is loading properly; and determining whether themedical control application is running properly.
 19. The wireless bodyarea network of claim 16, wherein performing comprises: initiating averification protocol, via the application at the non-medical clientdevice when the application at the non-medical client device detectsoccurrence of the trigger event, wherein the verification protocolcomprises: executing one or more diagnostic checks to verify whether themedical control application is functioning properly and has access toadequate computing resources, wherein the computing resources includeprocessing resources, communication resources, user interface resources,and memory resources.
 20. The wireless body area network of claim 16,wherein the one or more remedial correction measures attempt to correctissues that are causing the non-medical client device to run improperlyso that the medical control application will function correctly and haveaccess to required computing resources, and wherein the one or moreremedial correction measures comprise one or more of: automaticallyclosing and restarting the medical control application; prompting theuser to change restart the medical control application of thenon-medical client device when it is determined that the medical controlapplication is not loading or is not running properly; automaticallypowering the non-medical client device off, automatically restartingnon-medical client device, and reopening the medical controlapplication; downloading and installing an up-to-date version of themedical control application or an up-to-date version of an operatingsystem when it is determined that the existing versions were notcorrect; prompting the user to change one or more settings of at leastone of the medical control application, the non-medical client device oran operating system of the non-medical client device when it isdetermined that one or more settings of the medical control applicationare incorrect; and freeing up additional computing resources of thenon-medical client device for use by the medical control applicationwhen it is determined that the medical control application does not haveaccess to adequate computing resources.